[レポート]AWS infrastructure as code: A year in review #DOP201 #AWSreInvent

はじめに

今回はre:Invent2024のセッション 「AWS infrastructure as code: A year in review」 について抜粋して紹介していきます。IaCのおさらいと1年間の振り返り的な内容だったので、これを見て思い出していただければ幸いです。

https://youtu.be/XpsonmjdIfA?si=S3Adh_MA3YO8-rFo

Cfn/CDK/Cloud Control APIの話が前半のメインで、後半最後にはNetflixの事例が紹介されます。今年1年のCfn周りのアップデートの総ざらいとNetflixの事例でCloud Control APIを直接使う場合の事例が聞けるので大変興味深かったので、ぜひ聞いてみてください！

セッションの概要

「AWS infrastructure as code: A year in review」

概要文（Youtubeより）

AWS provides services that enable the creation, deployment and maintenance of application infrastructure in a programmatic, descriptive, and declarative way. These services provide rigor, clarity, and reliability to application development. Join this session to learn about the new features and improvements for AWS infrastructure as code with AWS CloudFormation and AWS Cloud Development Kit (AWS CDK) and discover how they can benefit your team.

翻訳

AWSは、アプリケーションインフラストラクチャの作成、デプロイ、保守をプログラム的、記述的、宣言的な方法で実現するサービスを提供しています。これらのサービスは、アプリケーション開発に厳密性、明確性、信頼性をもたらします。このセッションでは、AWS CloudFormationとAWS Cloud Development Kit（AWS CDK）によるAWSインフラストラクチャ・アズ・コードの新機能と改善点について学び、それらがチームにもたらすメリットを発見してください。

登壇者(順不同)

• Ben Perak氏(AWS/Product Lead, IaC)
• James Hood氏(AWS/Principal Engineer, IaC)
• Nick Siow氏(Netflix/Staff Security Engineer)

セッション内容

目次

• PAST What tools we offer
• PRESENT What we launched this year
• FUTURE What's next

What tools we offer

Ben Perak氏より

最初は簡単なCloudFormationの例の紹介からでした。CfnでS3バケットを作成するyamlを例にIaCを紹介しています。
その後に今回のアジェンダで、既存のツールの紹介、今年何を作ったか、今後の3点。特に今年何を作ったか重点的に話すことに触れられました。

以下の図は上に行くほど抽象的なツールとなります。Cfnは2011年に登場し、人々の手動プロビジョニングの手間を減らす必要にかられ誕生しました。バージョン管理やインフラの複製を簡単にしました。Cfnの後に、ユーザのケースによってサーバレスアプリで長いyamlを書きたくないというケースに対してSAMが生まれました。また、AWS上でのフロントアプリのよりよい開発としてAmplifyが生まれました。CDKは後ほど話します。

これらのツールは社外向けだけでなく、社内向けにもオーケストレーションツールとして機能しました。
ここからはCDKについて話します。明らかにCDKに移行する人が増え始めています。インフラのオーケストレーションに優れたツールです。Constructは優れた強力なコンポーネントです。単一のリソースが複数のリソースをコントロールできるようになります。

下のレイヤーはどうでしょう。新しいリソースが追加されるとControl APIのリソースカバレッジが必要になります。AWSサービスはAWSリソースモデルを中心に標準化され始めています。AWS全体の標準化は、実はこのリソースレジストリに基づいて行われています。

多くのリソースをこの標準にマイグレーションする必要がありました。現在は97%が標準モデルに移行しています。熱心なCfnユーザならインポートやドリフト検出をサポートするAWSサービスが増えていることに気づいてるかもしれません。これはリソースレジストリへの統合によって可能になっています。この結果に満足しています。

標準リソースをすべてそろえたのでそのためのインターフェースを提供しようと考えて作ったのがCloud Control API(以降CC API)です。サードパーティー製品ではCC APIを使ってプロバイダーを立ち上げています。TerraformはCC APIの提供がGAしました。

次に顧客が何を求めているのかについて話します。1つ目は開発スピード、2つ目は安全性、3つ目はガバナンスです。詳細は以降に譲ります。

What we launched this year

James Hood氏より

AWS勤務15年、Cfnチームでは5年働いており、その前は5年間Cfnのユーザでした。まずは開発スピードの話から始めます。

開発スピードに関するアップデート

手動リソースを途中から慣れてきてIaCに変えていくのは困難でした。2月にこの重労働の代わりとなるIac Generaterを開発しました。Click OPSでIaCが可能になります。指定したリソースに関連するリソースもまとめてIaC化できます。

次も開発スピードです。内部ループを早くすることが重要ですが、プロビジョンの時間やエラーレスポンス、トラブルシューティングでスピードは悪化していきます。そのため、統計的に40%の時間削減を実行しました。これはどう実現したのでしょうか。re:InventはLearningイベントなのでご紹介します。

Cfnはスタックを並行してデプロイしていました。ただECSをデプロイするような場合、以下のようにECRの完了を待ってからECS TaskDefinitionを待つ必要がありました。これら依存関係のチェーンがプロビジョニングに影響していました。

またIAMロールの場合について話します。1秒未満の待機時間で返される場合と追加の非同期アクティビティを実行する場合には違いがあります。ロールを引き受ける場合に遅延が起きます。リソース作成は大まかに、Configuration CompleteとStabilizedに別れます。Configuration Completeしていても、Stabilizedになり使用可能になるまで処理を待っていました。

以下のようにそれぞれのリソースが、Stabilizedになるまで待つような安定的な実装になっていました。ただ多くの場合はリソースが完全に安定する必要はなく、楽観的に次の作成を開始しても良いはずです。

新しい楽観的な戦略では、Configuration Completeを契機に後続の処理を行うこととしました。これにより並列処理が改善し、全体の処理時間を削減できるようになりました。

また楽観的な戦略でエラーが出た場合は、リソースがStabilizedになるのを待ってから作成するように実装されています。この場合でも最初の戦略に比べて時間を削減することが可能になっています。

この変更は根本的なものでした。毎週大量のスタックを更新しているので、非常にゆっくりと展開する必要がありました。顧客はオプトインなどの必要もなく恩恵を受けます。この価値を感じてもらえると幸いです。

数ヶ月前にCfnでのタイムラインビューにも対応しました。相互のリソースの関係性をよりよく理解するのに役立ちます。顧客が実際にテンプレートを展開した際に最適化出来ているかを確認できます。

サイクルの改善には他の点も考慮が必要です。エラーに早く気づくことで。設定ミスが後半になって気づくようになっていると時間がかかります。なので、50%のリクエストを6.2倍高速化し、90%のエラーレスポンスを17倍高速にしました。またカスタムリソースのデフォルトタイムアウトを1時間から秒単位に変更しました。

さらに「根本の原因」を確認するためのボタンを追加しました。CloudTrailの情報をベースに原因の特定を早めます。またAmazon Qボタンを設置し、問題解決に取り組みやすくしました。

他にもLinterとしてcfn-lintやRain、Amazon Qがあります。（アップデートではないので割愛）

CDKについても紹介します。L2 Constructはもっとも使用されているConstructで、デベロッパーフレンドリーなリソース構築の体験が出来ます。最初はVPCの新しいL2 Constructが出ました。次にCloudFrontのOAC対応がありました。これはCDKユーザからもっともリクエストされたL2 Constructです。2つの新しいL2 Constructもあります、1つはKinesis Data Firehose、2つ目はCognito identity poolです。

またCDK実行時にS3やECRの古いデータを削除しコストを削減する機能や、CDKがIAMロールを引き受けて1時間立つとタイムアウトする問題をセッションタグで解決した機能もあります。

以上が開発スピードに関する話です。次は安全性についてです。

安全性に関するアップデート

Cfnなどは事前検証はしますが実際に検証しないと正常なものかはわかりません。Changesetの改善がありました。ここではLambdaの例を見てみます。この例から想定と実態がかなり異なることがわかります。実行時プロパティが変更されることで誤った値に変更されることもあります。

ポーリングリクエストを送るとChangeSetをベースにしたコメントをGitHubに送る機能を作りました。（この機能はGit Syncを使っている場合限定の機能です）

Amazon社内での使用例を紹介します。Change Guardianと呼んでいるものでは、Cfnの変更でハイリスクなものをブロックするか承認するか選択させます。(筆者も調べたりしたのですがChange Guardianの詳細はわからず…)
次にガバナンスについてです。

ガバナンスに関するアップデート

James Hood氏より

開発者の自由とセキュリティ/コンプリナンスは天秤です。社内で開発者が使えるようなゴールデンパスは用意していますか？ルールによる検出と修正は開発者に多くの負荷がかかり高価にもなります。事前にCloudFormation Hookを通すことで検知できます。プロアクティブなコントロールは非常に有効な手段です。

私達は大体18ヶ月ぐらい前にHooksを立ち上げました。最初はLambdaを指定するHookを作成しました。追加料金はLambda以外にかかりません。2つ目としてGuardを作りました。OSSの宣言的ポリシーを宣言して確認できます。Guardは公開されているものもあり、リソース更新時に毎回適用できます。

現在チェックはデプロイ前に実行できます。これはTerraform/Pulumiなどにも提供されています。次にスタック用のHook、ChangeSet用のHookが提供されています。

Cox Automotiveの事例を紹介します。彼らは事前チェックの方法を探していました。彼らはDetective ScanningのルールをHooksに寄せて、DetectiveからProaciteveにガバナンスへの適用が可能になりました。

最後に実際の顧客事例を紹介します。

Customer showcase(Netflix)

Nick Siow氏より

NetflixではIAMに関してはConsole meというOSSツールがあり、EC2に関するIAM変更の大部分を管理しています。SpinnakerでEC2を管理しています。ただ他のクラウドプリミティブなサービスを操作する道が整備されていませんでした。チームによってはCfn、Terraform、それ以外の独自の方法を使っていました。それを開発者にセルフサービスで使ってもらう方法を考えました。

最小限のゴールデンパスを作りたいと考えました。そのため、コンソールやCfnの利用は避けることとしました。CC APIで簡単にリソースをコントロールすることを望みました。ここからはデモでSpinnaker経由でCC APIを使ってガバナンスに適したAWSリソースが作成されるデモでした。

k8s platformとCC APIを統合することで、YAMLテンプレートを作るとガバナンスや要件に適したAWSリソースが作成されるようなシステムを構築しました。

なぜCC APIを使うのか。理由はいくつかあります。まずはカバレッジです、多くのAWSリソースへの操作を標準化したいと考えています。Cfnではうまく行かない場合もCC APIなら独自の形式で取り込むことはうまく出来ました。CfnスタックやTerraformステートのような概念はありません。CC APIのエコシステムには使用したい機能もあり、ドリフトマネジメントは重要でした。ドリフトによって希望通りに修正できます。多くのAPIも使用したいし、リソースが自分たちの単位で管理できるので非常に強力なツールです。社内でIaCソリューションを検討しているなら是非試してみてください。

What's next

3つの中核領域への高速化も継続して取り組んでいきます。しかし私が興味深いと考えていること別にもあります。
テンプレートは一方的にリソースを作成しますが、ドリフトが起きるとコンソールを見て変更が必要になります。双方向での変更を反映数方法を考えています。ClickOpSとIaCの境をなくすような、来年はこの分野に取り組みます。

Cfn/CDKに取り組むためのワークショップやSlack/Discordなどもあるので是非アクセスしてください。

所感

Cfn/CDKアップデートの振り返りがてら見てましたが、Cfnのデプロイ性能改善の裏の仕組みの話や途中からCC APIだけ使って自分たちでIaCを作る話など盛りだくさんで面白かったです。気になった方は是非本編で詳細を聞いてみてください！

製造ビジネステクノロジー部佐藤智樹でした。